Cloudron Forum

This sounds very confusing, but my answer, as I understand the question, is that Cloudron only manages domains, and subdomains, which have the A record for the Cloudron VPS. So if your Cloudron is at a server with an IP 1.2.3.4, then your DNS will have an A record of example.com at 1.2.3.4, with the *.example.com also having 1.2.3.4. BUT, you can make any number of other A records like grampwebs.example.com but the A record is 4.3.2.1, and that will resolve fine on the other server. Cloudron doesn't "have" sub-domains per se, only what the * allows combined with the subdomains you enter in the app installation. I supposed it does "have" it in the sense that any crazyname.example.com is going to resolve to the CLoudron, along with a message saying there is no app there (because of the *), but again, DNS is up to you and your registrar, not Cloudron. I should add that I use Wildcard, even with the Registrars that Cloudron can interact with using the API, simply because I like being that one-more-step-closer-in-control, and because sometimes I do use the Cloudron root domain with a different subdomain resolving to an entirely different server and web app.

Thanks sorry did not see that 😃

@doon Perhaps you can do a writeup as a guide for the rest of the forum on your use case?

I forked this into a separate thread.

Think we need some more context. Are you saying using localhost:port of your MacOS device does not work with the app proxy anymore? In the recent releases, an app proxy related change that happened is that we set the Host header to the initial request endpoint. Would your set up be affected by this change by any chance? Related issue in NPM - https://github.com/NginxProxyManager/nginx-proxy-manager/issues/127

@nebulon test, as in previous testing proxying across cloudrons, and to other search engines worked just fine, and these tools sites, didn't.

@robi new cloudron release

I've tried to use pgadmin and jupyter notebook under App Proxy today and I can confirm that the issue still exists, since /login/ locations are required by both apps but are also reserved for cloudron. Pretty annoying !

@joseph : this is not solved, can you unmark it?

@MooCloud_Matt I think you can just use "no-op" in your situation and also use a custom wildcard certificate. The proxy can then accept just that wildcard cert.

no-op ignores DNS checks. The cert can be Let's Encrypt or not depending on if your proxy can carefully forward well-known HTTP requests.

@girish Perfect, that's where I went wrong, thanks.

Thanks for the insights, @arshsahzad and @girish, I’ll explore these solutions.

As for tailscale and cloudflare, I’d have to set them up externally to cloudron on the server, right? Which I’ve always thought was not recommended.

Think I’ll try it anyway and get back to you guys. I’ve already setup a vpn on my home server with wireguard so maybe I’ll go with that.

Thanks!

Feature request at https://forum.cloudron.io/topic/8487/enhance-app-proxy-app-with-path-and-port-support

@matthijs that's not possible because HTML/Javascript is opaque "data" and one cannot replace things without understanding what the data is.

For example, the HTML could say "Your IP is NOT xxxxx" or "Your friend is at IP yyyy" or just about anything else. There is no way to reliably replace HTML (other than the app itself).

@dominikjannis Do you think you can send me the IP address to support@cloudron.io ? I can test it out from my test instance.

@robi Thank you!!

Nginx Proxy Manager is a UI + LetsEncrypt for Nginx if I have to simplify it.

Do you have a sample Nginx proxy conf for this setup?
Thanks again!

Fixed in https://git.cloudron.io/cloudron/box/-/commit/84ba333aa11fe7d0e2ae00d2b1437efc27a876b4